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DETAILED ACTION 
Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114 was filed in this application 
after a decision by the Board of Patent Appeals and Interferences, but before the filing of a 
Notice of Appeal to the Court of Appeals for the Federal Circuit or the commencement of a civil 
action. Since this application is eligible for continued examination under 37 CFR 1.1 14 and the 
fee set forth in 37 CFR 1 .17(e) has been timely paid, the appeal has been withdrawn pursuant to 
37 CFR 1.114 and prosecution in this application has been reopened pursuant to 37 CFR 1.114. 
Applicant's submission filed on 8/21/09 has been entered. 



Priority 

2. Applicant's claim for the benefit of a prior-filed application under 35 U.S.C. 1 19(e) or 
under 35 U.S.C. 120, 121, or 365(c) is acknowledged. Applicant has not complied with one or 
more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 1 19(e) as 
follows: 

The later- filed application must be an application for a patent for an invention which is 
also disclosed in the prior application (the parent or original nonprovisional application or 
provisional application). The disclosure of the invention in the parent application and in the later- 
filed application must be sufficient to comply with the requirements of the first paragraph of 35 
U.S.C. 112. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 
USPQ2d 1077 (Fed. Cir. 1994). 
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The disclosure of the prior- filed application, provisional Application No. 60/176,928, 
fails to provide adequate support or enablement in the manner provided by the first paragraph of 
35 U.S.C. 1 12 for claims 1-39, 42-50, 54-65 of this application. The disclosure of the prior-filed 
application, provisional Application No. 60/176,928 series of feature requirement for Multiple 
Service Control Point (MSCP) system where 

• the first document FAST MSCP feature requirement specification Re. 3.2 discloses 
authorization, data elements, activation, invocation, normal processing, reporting 
requirements and feature interactions, 

• the second document discloses transaction detail records Rel 3.2.0, 

• the third document disclose data schema requirement for call processing control Rel. 3.2, , 

• the fourth document discloses service administration interface Rel. 3.2, 

• fifth document discloses message and parameter specification Rel. 3.0.6 

• Sixth document discloses call flows Rel. 3.0, 

• Seventh document discloses network management requirement Rel. 3.0 

• eighth document discloses voice and telephony over ATM IWF 

• Ninth document discloses frame rely customer PVC reconfiguration 

• Tenth document discloses ATM signaling intercept processor with the GUI user guide to 
MCI WorldCOM computer system. 

These documents in provisional Application No. 60/176,928, mainly discloses generic 
specification of MSCP system that may relate to the field of invention, but there is no specific 
disclosure or clear evidence in these documents, "individually or in-combination", that provide 
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adequately support or enablement in the manner provided by the first paragraph of 35 U.S. C. 112 
for the claims 1-39, 42-50, 54-65 of this instant application. 

If applicant were to disagree, it is suggest providing each document name, number, page 
number and paragraph number of the document with the corresponding claim number. 

Specification 

3. The disclosure is objected to because of the following informalities: the status of a parent 
reference U.S. applications (09/768068, 09/768077, 09/767476, 09/768069, 09/768070) recited 
in page 2, line 18 must be updated as "now issued as U.S. Patent" or "now abandoned", and it 
is also suggested to remove all attorney docket numbers for these U.S. applications since they 
now have the corresponding U.S. application numbers and/or patent numbers, respectively. 

Appropriate correction is required. 

4. The specification is objected to as failing to provide proper antecedent basis for the 
claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the 
following is required: Claim 39 recites, "a computer readable medium" in line 1. However, the 
specification fails to provide intrinsic definition/embodiment of what a computer readable 
medium is. 

Claim Rejections - 35 USC §101 

5. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 
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6. Claims 39, 42-50, 54-65 are rejected under 35 U.S.C. 101 because the claimed invention 
is directed to non- statutory subject matter since it fails to be limited to embodiments which fall 
within a statutory category. 

Claim 39 recites, "a computer readable medium operable with an Asynchrous Transfer 
Mode (ATM) network node, said computer-readable medium carrying a sequence of instructions 
provided for executing logic which, when executed by a processing entity. . ." in line 1-3. 

It is noted that applicant fails to provide antecedent basis for the claim terminology 
"computer readable medium" intended to be covered within the meaning in the disclosure. Since 
the applicant fails to provide antecedent basic to limit the specific statutory embodiments, 
"computer readable medium" belongs to the intrinsic non-statutory embodiments of transitory 
medium such as a carrier signal, radio wave, light wave, and transmission medium/media. 

Transitory transmission media in the context of this disclosure cover "carrier signal, 
radio wave, light wave, transmission medium/media", which are not a Manufacture within the 
meaning of 101, and electrical connections, optical coaxial cables, copper wire and fiber optics 
fibers, on which the program is still unavailable to the processor. In such embodiments, the 
program is still unable to act as a computer component and have its functionality realized. Thus, 
claims that recite nothing but the physical characteristics of a form of energy, such as a 
frequency, voltage, or the strength of a magnetic field, define energy or magnetism, per se, and 
as such are nonstatutory natural phenomena. O'Reilly, 56 U.S. (15 How.) at 1 12-14. Thus, the 
claim is also non-statutory. 
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In view of the above analysis, claim 39 is ineligible for patent protection as failing to be 
limited to embodiments which fall within a statutory category. 

Claims 42-50 and 54-65 are also rejected since they are depended upon rejection claim 39 
set forth above. 

Claim Rejections - 35 USC §103 

7. The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

1. Claim 1-3,5, 11, 12,14-16,18, and 31 are rejected under 35 U.S. C. 103(a) as being 
unpatentable over Buyukkoc (US 6.463.062) in view of Gai (US006 167445 A). 

Regarding claim 1, Buyukkoc discloses a method in an synchronous Transfer Mode 
(ATM) network (see FIG. 7-9, a method performed by central Routing Status Database server, 
PvDS in ATM network; see col. 19, line 55-60) having an ingress switch (see FIG. 9, ATM 
switch 922) and an egress switch (see FIG. 9, ATM switch 924), wherein said ingress switch 
serves an ingress device (see FIG. 9, switch 912) operated by a calling party (see FIG. 9, User 
902) and said egress switch serves an egress device (see FIG. 9, Switch 914) operated by a called 
party (see FIG. 9, user 904); see col. 19, line 61 to col. 20, line 24), the method comprising: 

receiving, in said ingress switch, a signaling message from said ingress device (see FIG. 
9, step 810, edge node receive a new call; see col. 19, line 19-26; also see FIG. 10, step 
1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 
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providing said signaling message to a signaling intercept processor (see FIG. 7, a link 750 
to Regional RSD server, RRSD, 740; see col. 13, line 22-46) associated with said ingress switch 
(see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node send a call 
query/message to RSD; also see FIG. 10, step 1035); 

propagating said signaling message from the signaling intercept processor to a policy 
server (see FIG. 7, from regional RSD 740 (RRSD) via a link 770 to central RDS server 730, 
i.e., Signaling Control Point, SCP), said policy server being associated with a policy profile 
database ( Tables VII-IX, RSD associated with a database ), the policy profile database storing 
entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; see col. 10, line 
10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents consists 
call/connection rules/policies (e.g. features/description includes connectively information, 
threshold, quality of service, capacity, and/or status of loading/congestion), where a call is 
associated with a user/subscriber since the user/subscriber is the one making the 
call/connect) , where each policy defines one more policy features of a group of policy features 
with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality 
of service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of 
service feature/description of a group of features/descriptions connectively information, 
threshold, quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber); 
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Identifying in the policy profile database and based on the signaling message, a policy for 
the calling party (see col. 17, line 25 to col. 18, line 45; see col. 14, line 9 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; according to a new call, 
recognizing/identifying a specific rule/policy in the RSD rule/policy database tables VII- 
IX); 

determining, in the policy server and based on the signaling message, that the policy for 
the calling party is to be enforced (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 
17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; 
see col. 11, line 1-16; see col. 13, line 1-6, 29-67; Tables VII-IX; according to a new call in the 
RSD database tables, deciding/determining a specific rule/policy to trigger/apply to received 
call's priority of traffic); 

executing, in said policy server and based on said signaling message for each policy 
feature of the one or more policy features identified by the policy for the calling party (FIG. 8, 
step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 45; see col. 13, line 
1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29- 
67; according to a new call, processing/executing in RSD for each status/feature (i.e. 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion) of a group of status/feature/priority (i.e. connectively information, 
threshold, quality of service, capacity, and status of loading/congestion) identify/recognized 
by the rule/policy associated with a call/connection for the user/subscriber); 

determining whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party , is satisfied with respect to said 
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signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)); 

establishing a connection path between said ingress switch and said egress switch based 
on said determination that said policy condition is satisfied for each policy feature, of the one or 
more policy features identified by the policy for the calling party (see FIG. 8, step 850, 860, 870; 
see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, 
line 40-50; setting/establishing the call/connection when 

load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively information, 
threshold, quality of service, capacity, or status of loading/congestion) are met/fulfilled for 
each policy/rule status/feature identified/recognized by the user/subscriber policy). 

Although Buyukkoc discloses executing in said policy server for each policy feature of 
the one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose "appropriate service logic". 

However, Gai teaches said policy server (see FIG. 4, policy server 322) being associated 
with a policy profile database (see FIG. 4, a combined system of database policy rule 414, policy 
translator, repository 326 and device-specific filtering entity 416), the policy profile database 
storing entries that relate subscriber to policies (see FIG. 4, stores data related to user policies; 
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see col. 13, line 61 to col. 14, line 5), where each policy defines one more policy features of a 
group of policy features with which the related subscriber is associated (see FIG. 4, each policy 
defines rules/policy features for a group of policy features (e.g. source address screening, 
Destination address screening features) for each user; see col. 14, line 1-15, 56 to col. 15, line 
55); 

identifying, in the policy profile database, a policy for the calling party (see FIG. 4, 
identifying/recognizing the policy for a calling user in the combined database system; see col. 
13, line 60 and col. 18, line 65); 

Determining, in the policy server and that the policy for the calling party is to enforced 
(see FIG. 4, determining the policy for the caller/user is to be managed/restricted/enforced in the 
policy server 322; see col. 13, line 60 and col. 18, line 65);; 

executing in said policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one 
or more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

establishing the connection path based on said determination that said policy condition is 
satisfied for each policy feature, of the one or more policy features identified by the policy for 
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the calling party (see FIG. 4, establishing a connection/communication base on determination 
that policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized 
by the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 14, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy 
features with respect to a call to be established between a calling party and a called party (see 
FIG. 9, a connection user 904 and 902; see col. 19, line 61 to col. 20, line 24), comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by the calling party (see FIG. 9, CPE User 902 connects TDM switch 912; see 
col. 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch, the signaling intercept processor to intercept a 
signaling message relative to said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see 
col. 19, line 25-30; edge node send a call query/message to RSD, thus RSD intercept/capture 
the call query/message; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e., Signaling Control Point, SCP) 
associated with said signaling intercept processor, said policy server being associated with a 
policy profile database ( Tables VII-IX, RSD associated with a database ), the policy profile 
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database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; 
see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents 
consists call/connection rules/policies (e.g. features/description includes connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion), 
where a call is associated with a user/subscriber since the user/subscriber is the one making 
the call/connect) , where each policy defines one more policy features of a group of policy 
features with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality 
of service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of 
service feature/description of a group of features/descriptions connectively information, 
threshold, quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber) where said policy server is to; 

wherein said policy server operates to effectuate a particular policy feature of the 
plurality of policy feature with respect to said call when triggered by said signaling message 
received from said signaling intercept processor (see FIG. 8, step 840; see FIG. 10, steps 
1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; RSD determines/decides whether a particular/specific quality-of-service rule/policy of the 
load/congestion/priority/bandwidth/route/quality-of-service condition of a new call/connection is 
met/fulfilled when receiving setup message from a user (via RRSD)). 
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determining that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 
45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see 
col. 13, line 1-6, 29-67; Tables VII-IX; according to a new call in the RSD database tables, 
deciding/determining a specific rule/policy to trigger/apply to received call's priority of 
traffic); 

execute for each policy feature of the one or more policy features identified by the policy 
for the calling party (FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 
18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 
1-16; see col. 13, line 1-6, 29-67; according to a new call, processing/executing in RSD for 
each status/feature (i.e. connectively information, threshold, quality of service, capacity, or 
status of loading/congestion) of a group of status/feature/priority (i.e. connectively 
information, threshold, quality of service, capacity, and status of loading/congestion) 
identify/recognized by the rule/policy associated with a call/connection for the 
user/subscriber); 

determine whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to said 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
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call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party, is determined to be 
satisfied (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 
1-65; see col. 19, line 35-50; see col. 21, line 40-50; setting/establishing the call/connection 
when load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively 
information, threshold, quality of service, capacity, or status of loading/congestion) are 
met/fulfilled for each policy/rule status/feature identified/recognized by the user/subscriber 
policy). 

Although Buyukkoc discloses executing in said policy server for each policy feature of 
the one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose "appropriate service logic". 

However, Gai teaches said policy server (see FIG. 4, policy server 322) being associated 
with said intercept processor, said policy server being associated with a policy profile database 
(see FIG. 4, a combined system of database policy rule 414, policy translator, repository 326 and 
device-specific filtering entity 416), the policy profile database storing entries that relate 
subscriber to policies (see FIG. 4, stores data related to user policies; see col. 13, line 61 to col. 
14, line 5), where each policy defines one more policy features of a group of policy features with 
which the related subscriber is associated (see FIG. 4, each policy defines rules/policy features 
for a group of policy features (e.g. source address screening, Destination address screening 
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features) for each user; see col. 14, line 1-15, 56 to col. 15, line 55) where said policy server is 
to: 

determine that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 4, determining a policy for the caller/user in the combined database system is to 
be managed/restricted/enforced for caller user; see col. 13, line 60 and col. 18, line 65); 

execute in said policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one 
or more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party is determined to be 
satisfied (see FIG. 4, establishing a connection/communication base on determination that 
policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized by 
the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
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Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 39, Buyukkoc discloses a computer-readable medium operable with an 
Asynchronous Transfer Mode (ATM) network node (see FIG. 9, ATM switch 922,924), said 
computer-readable medium carrying a sequence of instructions provided for executing service 
logic which, when executed by a processing entity associated with said ATM network node, 
causes said ATM network node to perform the steps of: 

receiving in said ATM network node a signaling message with respect to a call from a 
calling party (see FIG. 9, User 902; see FIG. 9, step 810, edge node receive a new call; see col. 
19, line 19-26; also see FIG. 10, step 1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 
and 

identifying in the policy profile database associated with the ATM network node and 
based and based on the signaling message, a policy for the calling party (see col. 17, line 25 to 
col. 18, line 45; see col. 14, line 9 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1- 
16; see col. 13, line 1-6, 29-67; according to a new call, recognizing/identifying a specific 
rule/policy in the RSD rule/policy database tables VII-IX); 

the policy profile database ( Tables VII-IX, RSD associated with a database ), the policy 
profile database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, 
line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores 
contents consists call/connection rules/policies (e.g. features/description includes 
connectively information, threshold, quality of service, capacity, and/or status of 
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loading/congestion), where a call is associated with a user/subscriber since the 
user/subscriber is the one making the call/connect) , where each policy defines one more 
policy features of a group of policy features with which the related subscriber is associated (see 
col. 14, line 35-64; each rule/policy defines/describes the descriptions/features of 
connectively information, threshold, quality of service, capacity, and/or status of 
loading/congestion (i.e. a policy/rule for a quality of service feature/description of a group 
of features/descriptions connectively information, threshold, quality of service, capacity, 
and/or status of loading/congestion; a policy/rule for loading/congestion feature/description 
of a group of features/descriptions connectively information, threshold, quality of service, 
capacity, and/or status of loading/congestion) associated with a call/connection for the 
user/subscriber) 

executing, based on the signaling message, for each policy feature of the one or more 
policy features identified by the policy for the calling party (FIG. 8, step 840; see FIG. 10, steps 
1035,1040; see col. 17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; according to a new call, 
processing/executing in RSD for each status/feature (i.e. connectively information, 
threshold, quality of service, capacity, or status of loading/congestion) of a group of 
status/feature/priority (i.e. connectively information, threshold, quality of service, capacity, 
and status of loading/congestion) identify/recognized by the rule/policy associated with a 
call/connection for the user/subscriber); 

determining whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to said 
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signaling message ( see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)); 

upon determining that the policy condition associated with each policy feature of one or 
more policy feature identified by the policy for the calling party is satisfied with respect to said 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow, Red, and green), associated/related with 
connectively information, threshold, quality of service, capacity, or status of 
loading/congestion, identified/recognized by the rule/policy associated with a 
call/connection for the user/subscriber is met/fulfilled according to a new call/connection 
(i.e. load/congestion/priority /bandwidth/routes/quality-of-service states/conditions)^ 
causing a connection path to be established between the calling party and the call party (see FIG. 
8, step 850, 860, 870; see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, 
line 35-50; see col. 21, line 40-50; setting/establishing the call/connection when 
load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively information, 
threshold, quality of service, capacity, or status of loading/congestion) are met/fulfilled for 
each policy/rule status/feature identified/recognized by the user/subscriber policy). 
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Although Buyukkoc discloses executing in said policy server for each policy feature of 
the one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose "appropriate service logic". 

However, Gai teaches said policy server (see FIG. 4, policy server 322) being associated 
with said intercept processor, said policy server being associated with a policy profile database 
(see FIG. 4, a combined system of database policy rule 414, policy translator, repository 326 and 
device-specific filtering entity 416), the policy profile database storing entries that relate 
subscriber to policies (see FIG. 4, stores data related to user policies; see col. 13, line 61 to col. 
14, line 5), where each policy defines one more policy features of a group of policy features with 
which the related subscriber is associated (see FIG. 4, each policy defines rules/policy features 
for a group of policy features (e.g. source address screening, Destination address screening 
features) for each user; see col. 14, line 1-15, 56 to col. 15, line 55) where said policy server is 
to: 

determine that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 4, determining a policy for the caller/user in the combined database system is to 
be managed/restricted/enforced for caller user; see col. 13, line 60 and col. 18, line 65); 

execute in said policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one 
or more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
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determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

a connection path being established when the policy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party is determined to be 
satisfied (see FIG. 4, establishing a connection/communication base on determination that 
policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized by 
the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service policies; see Gai col. 5, line 45-55. 

OLD 

2. Claims 1-3,5,11,12,14-16,18, and 31 are rejected under 35 U.S.C. 102(e) as being 
anticipated by Buyukkoc (US 6.463.062). 

Regarding claim 1, Buyukkoc discloses an intelligent policy server (see FIG. 7-9, 
central Routing Status Database server, RDS) method in an synchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) having an ingress switch (see FIG. 
9, ATM switch 922) and an egress switch (see FIG. 9, ATM switch 924), wherein said ingress 
switch serves an ingress device (see FIG. 9, switch 912) operated by a calling party (see FIG. 9, 
User 902) and said egress switch serves an egress device (see FIG. 9, Switch 914) operated by a 
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called party (see FIG. 9, user 904); see col. 19, line 61 to col. 20, line 24), comprising the steps 
of: 

receiving, in said ingress switch, a signaling message from said ingress device (see FIG. 
9, step 810, edge node receive a new call; see col. 19, line 19-26; also see FIG. 10, step 
1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 

providing said signaling message to a signaling intercept processor (see FIG. 7, a link 750 
to Regional RSD server, RRSD, 740; see col. 13, line 22-46) associated with said ingress switch 
(see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node send a call 
query/message to RSD; also see FIG. 10, step 1035); 

propagating said signaling message to a policy server (see FIG. 7, a link 770 to central 
RDS server 730, i.e., Signaling Control Point, SCP), said policy server including at least one 
policy profile associated with a plurality of policy features (see col. 14, line 9 to col. 15, line 50; 
see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD contents consists 
connection rules/policy such as connectively information, threshold, quality of service, capacity, 
and/or status of loading/congestion), each policy profile of the at least one policy profile being 
associated with a subscriber (see col. 14, line 35-64; a quality of service rule/policy is one of the 
rule/policy associated with a call, where a call is associated with a user/subscriber); 

determining in said policy server, based at least in part on said signaling message, if a 
particular policy feature of the plurality of policy features is to be invoked (see FIG. 8, step 840; 
see FIG. 10, steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; decide 
how to route the call in accordance RSD contents by determining and triggering/invoking a 
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particular/specific quality-of-service rule/policy of connection rules/policies for received call's 
priority of traffic); 

if so, determining whether a policy condition associated with said particular policy 
feature is satisfied with respect to said signaling message (see FIG. 8, step 840; see FIG. 10, 
steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, 
line 19-30; determines/decides whether the load/congestion/priority/bandwidth/routes/quality-of- 
service conditions are met/fulfilled); 

establishing a connection path between said ingress switch and said egress switch based 
on said determination that said policy condition is satisfied by said signaling message (see FIG. 
8, step 850, 860, 870; see FIG. 10, steps 1045,1050,1055; see col. 14, line 1-65; see col. 19, line 
35-50; see col. 21, line 40-50; setting/establishing the call when 
load/congestion/priority/bandwidth/routes conditions are met/fulfilled). 

Regarding claims 2, 15, Buyukkoc discloses wherein said signaling message comprises 
a Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 3,5,16,18, Buyukkoc discloses wherein said signaling message 
comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a 
new call requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see 
col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

Regarding claim 11, Buyukkoc discloses an aggregated bandwidth limit feature (see col. 
17, line 30-40; see col. 13, line 45-47; total bandwidth). 
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Regarding claim 12, Buyukkoc discloses a service class selection feature (see col. 10, 
line 50-55; see col. 18, line 26-45; class-of-service). 

Regarding claim 31, Buyukkoc discloses a service class selection feature for specifying 
a service class with respect to a network port used by said party (see col. 10, line 50-55; see col. 
18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of-service for a 
port/link/trunk/circuit used by the call). 

3. Claim 4 and 17 are rejected under 35 U.S. C. 103(a) as being unpatentable over Buyukkoc 
in view of Noake (US006751222B1). 

Regarding claims 4 and 17, Buyukkoc does not explicitly disclose a release message. 
However, a release message is well know in the ATM signaling/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the system of 
Buyukkoc, so that it would make effective use of a band and the respective apparatus by 
transmitting connection information, and by sending/receiving a release message it will notify to 
stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; col. 8, line 
19-24. 



4. Claims 6-9,19-21,23, and 25 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buyukkoc in view of Christie*656 (US006690656B1). 
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Regarding claims 6, 8 and 9, Buyukkoc does not explicitly disclose a source address 
validation/screening and a destination address screening. However, a source address 
validation/screening is well known in the ATM signaling/SS7. In particular, Christie'656 teaches 
a source address validation/screening and a destination address screening (see FIG. 7; see col. 7, 
line 9-19, 35-45; checking/validating caller number in ANI and verifying a dial number). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number and dial number, as taught by 
Christie'656 in the system of Buyukkoc, so that it would can validate the calls and generate a 
billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 19, Buyukkoc discloses accessing said ATM network through a 
particular network port associated with said CPE (see FIG. 9, accessing Switch 922 through the 
trunk/port 932; see col. 20, line 1-10). 

Buyukkoc does not explicitly disclose a source address validation for ensuring that said 
party is an authorized party for accessing the network. 

However, a source address validation for ensuring that said party is an authorized party 
for accessing the network is well known in the art of signaling in order to established the call. In 
particular, Christie'656 teaches a source address validation for ensuring that said party is an 
authorized party for accessing the ATM network (see FIG. 7; see col. 7, line 9-19, 35-45; 
checking/validating caller number in ANI for verification for accessing ATM network). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number to access the ATM network, as taught by 
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Christie'656 in the system of Buyukkoc, so that it would can validate the calls and generate a 
billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 20, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port between customer and the network). Christie'656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 21, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

Regarding claim 23, Buyukkoc does not explicitly disclose a destination address 
screening for defining a plurality of address to which said party can effectuate said call. 
However, a destination address/number validation/screening for defining a plurality of 
address/numbers to which said party can effectuate said call is well known in the signaling with 
SCP. In particular, Christie'656 teaches a destination address screening for defining a plurality of 
address to which said party can effectuate said call (see FIG. 7; see col. 7, line 9-19, 35-45; see 
col. 15, line 40-60; see col. 2, line 1-15; verifying a dial number from the list of numbers where 
the call needs to be connected). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to validate/verify dial number from the list of 
number to establish the call, as taught by Christie'656 in the system of Buyukkoc, so that it 
would can validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 
7, line 39-45. 

Regarding claims 25, Buyukkoc does not explicitly disclose a source address screening 
for defining a plurality of address from which said call can be initiated to said party. However, a 
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source address/number validation/screening for defining a plurality of address from which said 
call can be initiated to said party is well known in the signaling with SCP. In particular, 
Christie'656 teaches a source address screening for defining plurality of address from which said 
call can be initiated to said party (see FIG. 7; see col. 7, line 9-19, 35-45; see col. 15, line 40-60; 
see col. 2, line 1-15; verifying a caller number, from the list of numbers, to initiate a 
call/connection). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to validate/verify caller number from the list of number to 
initiate a call, as taught by Christie'656 in the system of Buyukkoc, so that it would can validate 
the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

5. Claims 7 and 22 are rejected under 35 U.S. C. 103(a) as being unpatentable over 
Buyukkoc in view of Farris (US006 154445 A). 

Regarding claim 7, Buyukkoc does not explicitly disclose a maximum call attempt rate 
limit. However, having a maximum call attempt rate limit/threshold is well known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). Therefore, it 
would have been obvious to one having ordinary skill in the art at the time the invention was 
made to provide acceptable/maximum specified rate of call attempts, as taught by Farris in the 
system of Buyukkoc, so that it would can detect the predetermined events and/or imminence of 
predetermined events, and then blocking or controlling those events from their incipiency; see 
Farris col. 14, line 1-6. 
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Regarding claim 22, Buyukkoc discloses the number of setup messages as described 
above in claim 18. 

Buyukkoc does not explicitly disclose a maximum call attempt rate limit for monitoring 
the number of messages received from said party over a predetermined period of time. However, 
having a maximum call attempt rate limit for monitoring the number of messages received from 
said party over a predetermined period of time is well known in the art of signaling and network 
management. In particular, Farris teaches a maximum call attempt rate limit for monitoring the 
number of setup messages received from said party over a predetermined period of time (see col. 
14, line 1-12; see col. 11, line 5-56; acceptable/maximum specified rate of call attempts for 
monitoring and determining the number of setup/ISUP messages from calling party per time 
period). Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide acceptable/maximum specified rate of call attempts and 
monitoring process, as taught by Farris in the system of Buyukkoc, for the same motivation as 
stated above in claim 7. 

6. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of VanDervort (US005761 191 A), or Horn (US005276676A). 

Regarding claim 10, Buyukkoc discloses a policy feature comprises a maximum size 
limit feature (see col. 14, line 15-65; acceptable/maximum load/size/bandwidth before the call 
are blocked). 

Buyukkoc does not explicitly disclose burst. However, ATM network having a 
rule/policy/policing attribute burst size threshold/limiting for ATM flow control is well known in 
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the art. In particular, VanDervort teaches a maximum burst size limit/threshold feature (see col. 

6, line 8-11; limited/maximum burst size limit/threshold of user cell transmission for policing). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to provide limited/maximum burst size, as taught by VanDervort in the 
system of Buyukkoc, so that it would control the flow of traffic and maximize the utilization of 
network resources; see VanDervort col. 6, line 1-3. 

Buyukkoc does not explicitly disclose burst. In particular, Horn teaches a maximum burst 
size limit/threshold feature (see col. 2, line 29-30; maximum burst length is limited by 
threshold). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide maximum burst length threshold, as taught by Horn in 
the system of Buyukkoc, so that it would avoid overflow problem due to long bursts; see Horn 
col. l,line 25-34. 

7. Claims 13 and 38 are rejected under 35 U.S. C. 103(a) as being unpatentable over 
Buyukkoc in view of Basso (US006633539B1). 

Regarding claim 13, Buyukkoc discloses a policy feature comprises a maximum call 
limit feature (see col. 14, line 15-65; acceptable/maximum call load/limit/bandwidth). 

Buyukkoc does not explicitly disclose concurrent. However, ATM network having a 
maximum concurrent call limit/threshed for call admission control (CAC) is well known in the 
art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, line 25-35; 
maximum allowed/limit number of concurrent connection/call). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to provide 



Application/Control Number: 09/766,943 Page 29 

Art Unit: 2463 

maximum concurrent connection, as taught by Basso in the system of Buyukkoc, so that it would 
control concurrent connections/calls to provide efficient protection against signaling congestion; 
see Basso col. 2, line 35-45. 

Regarding claim 38, Buyukkoc discloses a policy feature comprise a maximum call 
limit feature for specifying the total number of calls allowed concurrently with respect to a 
network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 
932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit for a 
trunk/port). 

Buyukkoc does not explicitly disclose concurrent. However, ATM network having a 
maximum concurrent call limit/threshed for call admission control (CAC) is well known in the 
art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, line 25-35; 
maximum allowed/limit number of concurrent connection/call). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to provide 
maximum concurrent connection, as taught by Basso in the system of Buyukkoc, so that it would 
control concurrent connections/calls to provide efficient protection against signaling congestion; 
see Basso col. 2, line 35-45. 

8. Claim 24 and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Christie'656, as set forth above in claim 14, and further in view of Gai 
(US006 167445 A). 
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Regarding claim 24, the combined of Buyukkoc and Christie'656 discloses destination 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 23. 

Neither Buyukkoc nor Gai explicitly discloses a group of subscribers. However, Gai 
teaches a policy server (see FIG. 4, policy server 322) comprising the particular policy feature 
(see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device-specific 
filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a destination 
screening feature for a group of subscribers to which the party belongs (see col. 14, line 1-15, 56 
to col. 15, line 55; applying destination addressing policy rule to a group of users (see FIG. 7A, 
marking users, admin users, executive users, etc.) where a specific user (see FIG. 7A, John Doe) 
belongs; see col. see col. 14, line 10-18). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide a destination screening 
feature for a group of subscribers to which the party belongs, as taught by Gai in the combined 
system of Buyukkoc and Christie '5 65, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 26, the combined of Buyukkoc and Christie'656 discloses source 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 25. 

Neither Buyukkoc nor Christie'656 explicitly discloses a group of subscribers. However, 
Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular policy 
feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device-specific 
filtering entity; see col. 13, line 61 to col. 14, line 5) including a source address screening feature 
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for the group of subscribers to which the party belongs (see col. 14, line 1-15, 56 to col. 15, line 
55; applying source addressing policy rule to a group of users (see FIG. 7A, marking users, 
admin users, executive users, etc.) where a specific user (see FIG. 7A, John Doe) belongs; see 
col. see col. 14, line 10-18). Therefore, it would have been obvious to one having ordinary skill 
in the art at the time the invention was made to provide a source address screening feature for the 
group of subscribers to which the party belongs, as taught by Gai in the combined system of 
Buyukkoc and Christie'656, so that it would ability to allocate network services and resources by 
applying high-level quality of service policies; see Gai col. 5, line 45-55. 

9. Claims 27-29 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Kobayashi (US 5,896,371). 

Regarding claims 27, Buyukkoc discloses a maximum burst size limit feature associated 
with said call (see col. 14, line 15-65; acceptable/maximum load/size before the call are 
blocked). 

Buyukkoc does not explicitly disclose limiting a burst-size request. However, limiting a 
burst-size request is well known in the art of ATM. In particular, Kobayashi teaches a maximum 
burst size limit feature for limiting a burst-size request associated with said call (see FIG. 6; see 
col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the number of cells transmitted in 
each call). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to limit the number of cells transmitted in each call, as taught by 
Kobayashi in the system of Buyukkoc, so that it would provide a flow control performed 
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cooperatively by the network and the terminal equipment and call accepted control is simplified; 
see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claim 28, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the system of Buyukkoc, for the same motivation as 
above in claim 27. 

Regarding claim 29, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
requested to be received, as taught by Kobayashi in the system of Buyukkoc, for the same 
motivation as above in claim 27. 

10. Claim 30 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Smith (US006222823B1). 

Regarding claim 30, Buyukkoc discloses an aggregated bandwidth limit feature for a 
particular network port by said party (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10; 
col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link). 
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Buyukkoc does not explicitly disclose for determining a maximum bandwidth allowable 
and authorized for use. However, determining the maximum bandwidth allowable for a particular 
port authorized for use by said party is well known in the art of ATM. In particular, Smith 
teaches determining the maximum bandwidth allowable for a particular port authorized for use 
by said party (see FIG. 1-2; see col. 9, line 5-45, and abstract; determining 
predetermined/allowable/authorized bandwidth for a particular port/connection of end station). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the system of Buyukkoc, so that it 
would cause the system control means to allocate a predetermined bandwidth and balance the 
bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

1 1 . Claims 32-37 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Kilkki (US006041039A). 

Regarding claims 32-37, Buyukkoc discloses service class as described above in claim 
31 and 58. Buyukkoc further discloses constant bit rate service (CBR) and variable bit rate 
service (VBR) (see col. 1, line 50-60). 

Buyukkoc does not explicitly disclose a real-time VBR service, non-real time VBR, 
unspecified bit-rate (UBR), and available bit-rate (ABR). However, the ATM class of services a 
real-time VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate 
(ABR) is well known in ATM standard. In particular, Kilkki teaches CBR, VBR, a real-time 
VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) (see 
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col. 1, line 54-67). Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide quality of service class defined by ATM standard, 
as taught by Kilkki in the system of Buyukkoc, so that it would provide a capability to manage 
increases in network load, supporting both real-time and non-real time application, and offering, 
in certain circumstances, a guaranteed level service quality; see Kilkki col. 1, line 44-53, also by 
using the ATM standard services, it will enable the service provider to interoperate between 
multi-vendor networks. 

12. Claim 39,40-43,45,50 and 58 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Buyukkoc in view of Gai (US006 167445 A). 

Regarding claim 39, Buyukkoc discloses a computer-readable medium operable with an 
Asynchronous Transfer Mode (ATM) network node (see FIG. 9, ATM switch 922,924), said 
computer-readable medium carrying a sequence of instructions provided for executing service 
logic which, when executed by a processing entity associated with said ATM network node, 
causes said ATM network node to perform the steps of: 

upon receiving in said ATM network node a signaling message with respect to a call 
from a party (see FIG. 9, User 902); see FIG. 9, step 810, edge node receive a new call; see col. 
19, line 19-26; also see FIG. 10, step 1005,1010,1015,1020,1025,1030; see col. 20, line 50-67), 
propagating said signaling message to a policy server (see FIG. 7-9, central Routing Status 
Database server, RDS) operably associated with said ATM network node (see FIG. 7, a link 770 
to central RDS server 730, i.e., Signaling Control Point, SCP); and 

upon determining that a policy condition associated with a particular policy feature to be 
invoked is satisfied with respect to said signaling message (see FIG. 8, step 840; see FIG. 10, 
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steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; decide how to route 
the call in accordance RSD contents by determining and triggering/invoking a particular/specific 
quality-of-service rule/policy of connection rules/policies for received call's priority of traffic), 
effectuating a treatment for said call based on said particular policy feature (see FIG. 8, step 850, 
860, 870; see FIG. 10, steps 1045,1050,1055; see col. 14, line 1-65; see col. 19, line 35-50; see 
col. 21, line 40-50; setting/establishing the call when load/congestion/priority/bandwidth/routes 
conditions are met/fulfilled (i.e. carrying/effectuating a action/treatment (by setting/establishing 
a call) when load/congestion/priority/bandwidth/routes conditions are met/fulfilled)).). 

Buyukkoc does not explicitly disclose one of a destination screening feature for a group 
of subscribers to which the party belongs or a source address screening feature for the group of 
subscribers. However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the 
particular policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, 
and device-specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of 
a destination screening feature for a group of subscribers to which the party belongs or a source 
address screening feature for the group of subscribers (see col. 14, line 1-15, 56 to col. 15, line 
55; applying source or destination addressing policy rule to a group of users (see FIG. 7 A, 
marking users, admin users, executive users, etc.) where a specific user (see FIG. 7A, John Doe) 
belongs; see col. see col. 14, line 10-18). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide one of a destination 
screening feature for a group of subscribers to which the party belongs or a source address 
screening feature for the group of subscribers, as taught by Gai in the system of Buyukkoc, so 
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that it would ability to allocate network services and resources by applying high-level quality of 
service policies; see Gai col. 5, line 45-55. 

Regarding claims 40, Buyukkoc discloses establishing a virtual channel connection 
between said party and another party for said call (see col. 20, line 5-45; virtual connection 
between users). 

Regarding claims 41, Buyukkoc discloses denying a virtual channel connection for said 
call (see col. 14, line 44-47; see col. 1, line 66-67; call is block, thereby, blocking the virtual 
connection due to congestion). 

Regarding claim 42, Buyukkoc discloses wherein said signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 43 and 45, Buyukkoc discloses wherein said signaling message 
comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a 
new call requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see 
col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

Regarding claim 50, the combined system of Buyukkoc and Gai discloses all limitation 
as set forth above in claim 39. Gai disclose a destination address screening and source address 
screening feature (see col. 14, line 1-15, 56 to col. 15, line 55; applying source and destination 
addressing policy rule; see col. see col. 14, line 10-18). Therefore, it would have been obvious to 
one having ordinary skill in the art at the time the invention was made to provide a destination 
screening feature and a source address screening feature, as taught by Gai in the system of 
Buyukkoc, for the same motivation as set forth above in claim 39. 
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Regarding claim 58, Buyukkoc discloses a service class selection feature for specifying 
a service class with respect to a network port used by said party (see col. 10, line 50-55; see col. 
18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of-service for a 
port/link/trunk/circuit used by the call). 

13. Claim 44 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth in claim 39 above, and further in view of Noake (US006751222B1). 

Regarding claim 44, neither Buyukkoc nor Gai explicitly disclose a release message. 
However, a release message is well know in the ATM signaling/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc and Gai, so that it would make effective use of a band and the respective 
apparatus by transmitting connection information, and by sending/receiving a release message it 
will notify to stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; 
col. 8, line 19-24. 

14. Claims 46-48 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, as set forth in claim 39 above, and further in view of Christie'656 
(US006690656B1). 

Regarding claim 46, Buyukkoc discloses accessing said ATM network through a 
particular network port associated with said CPE (see FIG. 9, accessing Switch 922 through the 



Application/Control Number: 09/766,943 Page 38 

Art Unit: 2463 

trunk/port 932; see col. 20, line 1-10). Gai discloses source address screening feature as set forth 
above in claim 39. 

Neither Buyukkoc nor Gai explicitly disclose ensuring that said party is an authorized 
party for accessing the network. 

However, a source address validation for ensuring that said party is an authorized party 
for accessing the network is well known in the art of signaling in order to established the call. In 
particular, Christie'656 teaches a source address validation for ensuring that said party is an 
authorized party for accessing the ATM network (see FIG. 7; see col. 7, line 9-19, 35-45; 
checking/validating caller number in ANI for verification for accessing ATM network). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to validate/verify the caller number to access the ATM network, as taught by 
Christie'656 in the combined system of Buyukkoc and Gai, so that it would can validate the calls 
and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 

Regarding claim 47, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port between customer and the network). Christie'656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 48, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 



15. Claim 49 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth above in claim 39, and further in view of Farris (US006 154445 A). 
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Regarding claim 49, Buyukkoc discloses the number of setup messages (see FIG. 8, 
steps 820,830; a message which contains a new call requesting for a route is the SETUP/adding 
party message in ATM signaling/SS7; see col. 19, line 19-31; see col. 20, line 46-52; see col. 20, 
line 39-45; see col. 21, line 19-25). 

Neither Buyukkoc nor Gai explicitly disclose a maximum call attempt rate limit for 
monitoring the number of messages received from said party over a predetermined period of 
time. However, having a maximum call attempt rate limit for monitoring the number of messages 
received from said party over a predetermined period of time is well known in the art of 
signaling and network management. In particular, Farris teaches a maximum call attempt rate 
limit for monitoring the number of setup messages received from said party over a predetermined 
period of time (see col. 14, line 1-12; see col. 11, line 5-56; acceptable/maximum specified rate 
of call attempts for monitoring and determining the number of setup/ISUP messages from calling 
party per time period). Therefore, it would have been obvious to one having ordinary skill in the 
art at the time the invention was made to provide acceptable/maximum specified rate of call 
attempts and monitoring process, as taught by Farris in the combined system of Buyukkoc and 
Gai, so that it would can detect the predetermined events and/or imminence of predetermined 
events, and then blocking or controlling those events from their incipiency; see Farris col. 14, 
line 1-6. 

16. Claim 65 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth above in claim 39, and further in view of Basso (US006633539B1). 
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Regarding claim 65, Buyukkoc discloses a policy feature comprise a maximum call 
limit feature for specifying the total number of calls allowed concurrently with respect to a 
network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 
932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit for a 
trunk/port). 

Neither Buyukkoc nor Gai explicitly disclose concurrent. However, ATM network 
having a maximum concurrent call limit/threshed for call admission control (CAC) is well 
known in the art. In particular, Basso teaches a maximum concurrent call limit feature (see col. 4, 
line 25-35; maximum allowed/limit number of concurrent connection/call). Therefore, it would 
have been obvious to one having ordinary skill in the art at the time the invention was made to 
provide maximum concurrent connection, as taught by Basso in the combined system of 
Buyukkoc and Gai, so that it would control concurrent connections/calls to provide efficient 
protection against signaling congestion; see Basso col. 2, line 35-45. 

17. Claims 54-56 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, as set forth in claim 39 above, and further in view of Kobayashi (US 5,896,371). 

Regarding claim 54, Buyukkoc discloses a maximum burst size limit feature associated 
with said call (see col. 14, line 15-65; acceptable/maximum load/size before the call are 
blocked). 

Neither Buyukkoc nor Gai explicitly disclose limiting a burst-size request. However, 
limiting a burst- size request is well known in the art of ATM. In particular, Kobayashi teaches a 
maximum burst size limit feature for limiting a burst-size request associated with said call (see 
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FIG. 6; see col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the number of cells 
transmitted in each call). Therefore, it would have been obvious to one having ordinary skill in 
the art at the time the invention was made to limit the number of cells transmitted in each call, as 
taught by Kobayashi in the combined system of Buyukkoc and Gai, so that it would provide a 
flow control performed cooperatively by the network and the terminal equipment and call 
accepted control is simplified; see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claim 55, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc and Gai, for the same 
motivation as above in claim 54. 

Regarding claim 56, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
requested to be received, as taught by Kobayashi in the combined system of Buyukkoc and Gai, 
for the same motivation as above in claim 54. 

18. Claim 57 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai, as set forth in claim 39, and further in view of Smith (US006222823B1). 
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Regarding claim 57, Buyukkoc discloses an aggregated bandwidth limit feature for a 
particular network port by said party (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10; 
col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link). 

Neither Buyukkoc nor Gai explicitly disclose for determining a maximum bandwidth 
allowable and authorized for use. However, determining the maximum bandwidth allowable for 
a particular port authorized for use by said party is well known in the art of ATM. In particular, 
Smith teaches determining the maximum bandwidth allowable for a particular port authorized for 
use by said party (see FIG. 1-2; see col. 9, line 5-45, and abstract; determining 
predetermined/allowable/authorized bandwidth for a particular port/connection of end station). 
Therefore, it would have been obvious to one having ordinary skill in the art at the time the 
invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the combined system of 
Buyukkoc and Gai, so that it would cause the system control means to allocate a predetermined 
bandwidth and balance the bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

19. Claims 59-64 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai, as set forth in claim 39, and further in view of Kilkki (US006041039A). 

Regarding claims 59-64, Buyukkoc discloses service class as described above in claim 
31 and 58. Buyukkoc further discloses constant bit rate service (CBR) and variable bit rate 
service (VBR) (see col. 1, line 50-60). 

Neither Buyukkoc nor Gai explicitly disclose a real-time VBR service, non-real time 
VBR, unspecified bit-rate (UBR), and available bit-rate (ABR). However, the ATM class of 
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services a real-time VBR service, non-real time VBR, unspecified bit-rate (UBR), and available 
bit-rate (ABR) is well known in ATM standard. In particular, Kilkki teaches CBR, VBR, a real- 
time VBR service, non-real time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) 
(see col. 1, line 54-67). Therefore, it would have been obvious to one having ordinary skill in the 
art at the time the invention was made to provide quality of service class defined by ATM 
standard, as taught by Kilkki in the combined system of Buyukkoc and Gai, so that it would 
provide a capability to manage increases in network load, supporting both real-time and non-real 
time application, and offering, in certain circumstances, a guaranteed level service quality; see 
Kilkki col. 1, line 44-53, also by using the ATM standard services, it will enable the service 
provider to interoperate between multi-vendor networks. 



Response to Arguments 

20. Applicant's arguments filed 1 1-16-2006 have been fully considered but they are not 
persuasive. 

Regarding claims 1-50,54-65, the applicant argued that, ". . .Buyukkoc does not 
disclose or suggest propagation a signaling message to a policy server, where the policy server 
includes at least one policy profile having a plurality of policy features, and where each policy 
profile of the at least one policy profile is associated with a subscriber. . .nowhere in Buyukkoc 
discloses or suggest that routing status database includes at least at least one policy profile 
having a plurality of policy features, and where each policy profile of the at least one policy 
profile is associated with a subscriber. . .Buyukkoc does not even mention policy profiles. . . "in 
page 27-33. 
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In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. Buyukkoc discloses propagating said signaling message (see FIG. 8, Step 820; 
see FIG. 10, step 1030; sends setup for a new call to RSD) to a policy server (see FIG. 7, a 
link 770 to central RDS server 730, i.e., Signaling Control Point, SCP), said policy server 
including at least one policy profile having a plurality of policy features (see col. 14, line 9 to 
col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD 
contents consists connection rules/policy such as connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion), and where each policy 
profile of the at least one policy profile being associated with a subscriber (see col. 14, line 35- 
64; a quality of service rule/policy is one of the rule/policy associated with a call, where a 
call is associated with a user/subscriber). 

Examiner asserts applicant's policy sever as Buyukkoc's RSD (see general response 
below). Also, examiner asserts applicant's "at least one policy profile" as Buyukkoc's "quality 
of service priority of a request call" (see general response below). 

Regarding claim 11, the applicant argued that, ". . .Buyukkoc teaches away from this 
feature. . .Buyukkoc does not discloses or suggest. . . a particular policy feature comprising an 
aggregate bandwidth limit feature. . ." in page 33-35. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. Buyukkoc discloses an aggregated bandwidth limit feature (see col. 17, line 30- 
40; see col. 13, line 45-47; total bandwidth). As recited above, claim 1 1 broadly recites, 
"aggregate bandwidth limit", and there no specific detailed of how "aggregate bandwidth limit" 
is determined, computed, or how such bandwidth is stored are being claimed. Thus, Buyukkoc 
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does not teach away from the applicant's invention of broadly cited "aggregate bandwidth limit" 
since Buyukkoc clearly teaches utilizing "total bandwidth" as a rule/policy for connection. 
Although the claims are interpreted in light of the specification, limitations from the specification 
are not read into the claims. See In re Van Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 
1993). 

Regarding claims 4 and 17, the applicant argued that, ". . .Noake is no way discloses 
or suggest. . .transmission of a Release message. . .to a policy server. . .one skilled in the art would 
not have been motivated to incorporated this alleged feature into the Buyukkoc system, absent 
impermissible hindsight. . ." in page 35-38. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. Regarding argument with respect to policy server, please see above response 
since the combined system of Buyukkoc and Noake "as a whole" discloses applicant claimed 
invention. Buyukkoc discloses a signaling message as set forth above. It is also well known and 
established in the art and fundamental step in telecommunication that when disconnecting a 
call/connection, the singling system (i.e. ATM signaling/SS7) release allocated resources by 
transmission of a Release message so that such recourses can be reallocated to other users for 
other calls/connections. In particular, Noake simply further discloses a signaling message of 
Buyukkoc as a specific "Release message" (see Noake FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the system of 
Buyukkoc, so that it would make effective use of a band and the respective apparatus by 
transmitting connection information, and by sending/receiving a release message it will notify to 
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stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; col. 8, line 
19-24. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 

Regarding claims 6, 8 and 9, the applicant argued that, ". . Christie for allegedly 
disclosing a source/destination address validation/screening and destination address screening. 
Applicants submit that Examiner's allegation does not address the specifically recited features of 
claims. . .examiner does not alleged, and Christie does not disclose or suggest, a policy 
server... thus examiner has not established a prima facie case of obviousness . . .motivation 
statement does not satisfy requirement of 35 USC 103 . . .Buyukkoc does not disclose or suggest a 
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desire to change the routing status database server. . .examiner's motivation is based on 
impermissible hindsight. . ." in page 39-44. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Regarding argument with respect to policy server, please see above response since the 
combined system of Buyukkoc and Christie "as a whole" discloses applicant claimed invention. 
Buyukkoc disclose policy/rule feature for establishing a connection. Source and destination 
addresses validation/screening are well known in the signaling (i.e. ATM signaling/SS7), in 
order to identify the caller validity. In particular, Christie'656 teaches a source/destination 
address validation/screening and a destination address screening (see FIG. 7; see col. 7, line 9- 
19, 35-45; checking/validating caller number in ANI and verifying a dial number). The 
examiner recognizes that obviousness can only be established by combining or modifying the 
teachings of the prior art to produce the claimed invention where there is some teaching, 
suggestion, or motivation to do so found either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/n re Jones, 958 F.2d 347, 21 USPQ2d 1941 
(Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to validate/verify the caller number (i.e. source address) and 
dial number (i.e. destination address), as taught by Christie'656 in the system of Buyukkoc, so 
that it would can validate the calls and generate a billing record; see Christie'656 col. 3, line 12- 
22; col. 7, line 39-45. Moreover, as set forth above, examiner is not require to show that 
Buyukkoc disclose or suggest a desire to change the routing status database server since the 
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motivation to combine can be found " either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art". In this case, Christie clearly discloses 
the motivation, and it is also well known knowledge generally available to one of ordinary skill 
in the art, as set forth above. Thus, it is clear that examiner has established a prima facie case of 
obviousness and the above motivation statement satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 

Regarding claims 7 and 22, the applicant argued that, ". . .examiner's allegations that 
Farris allegedly disclosing a maximum call attempt rate limit does not address the features 
recited in claim 7. Examiner does not alleged, and Farris does not disclose or suggest, a policy 
server... thus examiner has not established a prima facie case of obviousness . . .such motivation 
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statement does not satisfy requirement of 35 USC 103 . . .Buyukkoc does not disclose or suggest a 
desire to change the routing status database server. . .examiner's motivation is based on 
impermissible hindsight. . ." in page 45-47. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Regarding argument with respect to policy server, please see above response since the 
combined system of Buyukkoc and Farris "as a whole" discloses applicant claimed invention. 
Having a maximum call attempt rate limit/threshold is well known in the signaling/SS7. In 
particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1-12; see col. 11, 
line 5-17; acceptable/maximum specified rate of call attempts). 

The examiner recognizes that obviousness can only be established by combining or 
modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so found either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/n re Jones, 958 F.2d 347, 21 USPQ2d 1941 
(Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide acceptable/maximum specified rate of call 
attempts, as taught by Farris in the system of Buyukkoc, so that it would can detect the 
predetermined events and/or imminence of predetermined events, and then blocking or 
controlling those events from their incipiency; see Farris col. 14, line 1-6. Moreover, as set forth 
above, examiner is not require to show that Buyukkoc disclose or suggest a desire to change the 
routing status database server since the motivation to combine can be found " either in the 
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references themselves or in the knowledge generally available to one of ordinary skill in the 
art". In this case, Farris clearly discloses the motivation, and it is also well known knowledge 
generally available to one of ordinary skill in the art, as set forth above. Thus, it is clear that 
examiner has established a prima facie case of obviousness and the above motivation statement 
satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 

Regarding claim 10, the applicant argued that, "...examiner's allegations that 
VanDervort/Horn allegedly disclosing a maximum burst size limit feature does not address the 
features recited in claim 10. Examiner does not alleged, and VanDervort/Horn does not disclose 
or suggest, a policy server... thus examiner has not established a prima facie case of obviousness 
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. . .such motivation statement does not satisfy requirement of 35 USC 103 . . .Buyukkoc does not 
disclose or suggest a desire to change the routing status database server. . .examiner's motivation 
is based on impermissible hindsight. . ." in page 48-52. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Regarding argument with respect to policy server, please see above response since the 
combined system of Buyukkoc and VanDervort "as a whole" discloses applicant claimed 
invention. ATM network having a rule/policy/policing attribute burst size threshold/limiting for 
ATM flow control is well known in the art. In particular, VanDervort teaches a maximum burst 
size limit/threshold feature (see col. 6, line 8-11; limited/maximum burst size limit/threshold 
of user cell transmission for policing). Horn teaches a maximum burst size limit/threshold 
feature (see col. 2, line 29-30; maximum burst length is limited by threshold). 

The examiner recognizes that obviousness can only be established by combining or 
modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so found either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/n re Jones, 958 F.2d 347, 21 USPQ2d 1941 
(Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide limited/maximum burst size, as taught by 
VanDervort in the system of Buyukkoc, so that it would control the flow of traffic and maximize 
the utilization of network resources; see VanDervort col. 6, line 1-3. Also, in this case, it would 
have been obvious to one having ordinary skill in the art at the time the invention was made to 
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provide maximum burst length threshold, as taught by Horn in the system of Buyukkoc, so that it 
would avoid overflow problem due to long bursts; see Horn col. 1, line 25-34. 

Moreover, as set forth above, examiner is not require to show that Buyukkoc disclose or 
suggest a desire to change the routing status database server since the motivation to combine can 
be found " either in the references themselves or in the knowledge generally available to one 
of ordinary skill in the art". In this case, VanDervort/Horn clearly discloses the motivation, 
and it is also well known knowledge generally available to one of ordinary skill in the art, as set 
forth above. Thus, it is clear that examiner has established a prima facie case of obviousness and 
the above motivation statement satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 
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Regarding claims 13 and 38, the applicant argued that, ". . examiner's allegations that 
Basso allegedly disclosing a maximum concurrent call limit does not address the features recited 
in claim 13. Examiner does not alleged, and Basso does not disclose or suggest, a policy 
server... thus examiner has not established a prima facie case of obviousness . . .such motivation 
statement does not satisfy requirement of 35 USC 103 . . .Buyukkoc does not disclose or suggest a 
desire to change the routing status database server. . .examiner's motivation is based on 
impermissible hindsight. . ." in page 52-54. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Regarding argument with respect to policy server, please see above response since the 
combined system of Buyukkoc and Basso "as a whole" discloses applicant claimed invention. 
ATM network having a maximum concurrent call limit/threshed for call admission control 
(CAC) is well known in the art. In particular, Basso teaches a maximum concurrent call limit 
feature (see col. 4, line 25-35; maximum allowed/limit number of concurrent 
connection/call). The examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention where 
there is some teaching, suggestion, or motivation to do so found either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art. See In 
re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/n re Jones, 958 F.2d 347, 21 
USPQ2d 1941 (Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide maximum concurrent connection, as 
taught by Basso in the system of Buyukkoc, so that it would control concurrent connections/calls 
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to provide efficient protection against signaling congestion; see Basso col. 2, line 35-45. 
Moreover, as set forth above, examiner is not require to show that Buyukkoc disclose or suggest 
a desire to change the routing status database server since the motivation to combine can be 
found " either in the references themselves or in the knowledge generally available to one of 
ordinary skill in the art". In this case, Basso clearly discloses the motivation, and it is also well 
known knowledge generally available to one of ordinary skill in the art, as set forth above. Thus, 
it is clear that examiner has established a prima facie case of obviousness and the above 
motivation statement satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 
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Regarding claims 39-50,54-65, the applicant argued that, ". . .Buyukkoc does not 
disclose or suggest upon determining that a policy condition associated with a particular policy 
feature to be invoked is satisfied with respect to said signaling message, effectuating a treatment 
for said call based on said particular policy feature, the particular policy feature including at least 
one of a destination address screening feature for a group of subscribers to which the party 
belongs or a source address screening feature for the group of subscribers. . . one skilled in the art 
would not have been motivated to incorporate this alleged teaching for Gai into Buyukkoc, 
absent impermissible hindsight. . .such motivation statement does not satisfy requirement of 35 
USC 103..." in page 56-63. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Buyukkoc discloses upon determining that a policy condition associated with a particular 
policy feature to be invoked is satisfied with respect to said signaling message (see FIG. 8, step 
840; see FIG. 10, steps 1035,1040; see col. 13, line 1-7; 64 to col. 14, line 67; Tables VII-IX; 
decide how to route the call in accordance RSD contents by determining and 
triggering/invoking a particular/specific quality-of-service rule/policy of connection 
rules/policies for received call's priority of traffic), effectuating a treatment for said call based 
on said particular policy feature (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 
1045,1050,1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 40-50; 
setting/establishing the call when load/congestion/priority/bandwidth/routes conditions are 
met/fulfilled (i.e. carrying/effectuating a action/treatment (by setting/establishing a call) 
when load/congestion/priority/bandwidth/routes conditions are met/fulfilled)). Gai discloses 
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a policy server (see FIG. 4, policy server 322) comprising the particular policy feature (see 
FIG. 4, Policy Rule generation engine 414, policy translator 410, and device-specific 
filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a destination 
screening feature for a group of subscribers to which the party belongs or a source address 
screening feature for the group of subscribers (see col. 14, line 1-15, 56 to col. 15, line 55; 
applying source or destination addressing policy rule to a group of users (see FIG. 7A, 
marking users, admin users, executive users, etc.) where a specific user (see FIG. 7A, John 
Doe) belongs; see col. see col. 14, line 10-18). 

In response to applicant's arguments against the references individually, one cannot 
show nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re 
Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, the combined system 
of Buyukkoc and Gai "as a whole" discloses applicant claimed invention. 

The examiner recognizes that obviousness can only be established by combining or 
modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so found either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and/n re Jones, 958 F.2d 347, 21 USPQ2d 1941 
(Fed. Cir. 1992). In this case, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide one of a destination screening feature for a group 
of subscribers to which the party belongs or a source address screening feature for the group of 
subscribers, as taught by Gai in the system of Buyukkoc, so that it would ability to allocate 
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network services and resources by applying high-level quality of service policies; see Gai col. 5, 
line 45-55. Moreover, as set forth above, examiner is not require to show that Buyukkoc 
disclose or suggest a desire to change the routing status database server since the motivation to 
combine can be found " either in the references themselves or in the knowledge generally 
available to one of ordinary skill in the art". In this case, Gai clearly discloses the motivation 
as set forth above. Thus, it is clear that examiner has established a prima facie case of 
obviousness and the above motivation statement satisfy requirement of 35 USC 103. 

In response to applicant's argument that one would not be motivated to incorporate 
this alleged feature into Buyukkoc, the test for obviousness is not whether the features of a 
secondary reference may be bodily incorporated into the structure of the primary reference; nor 
is it that the claimed invention must be expressly suggested in any one or all of the references. 
Rather, the test is what the combined teachings of the references would have suggested to those 
of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). 

In response to applicant's argument that the examiner's conclusion of obviousness is 
based upon improper hindsight reasoning, it must be recognized that any judgment on 
obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so 
long as it takes into account only knowledge which was within the level of ordinary skill at the 
time the claimed invention was made, and does not include knowledge gleaned only from the 
applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 
170 USPQ 209 (CCPA 1971). 



21. 



The following responses are generally applicable to all applicant arguments. 
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I. Examiner assert the applicant's "policy server" as Buyukkoc's "RSD" as set forth 
above for the following reasons: 

Applicant disclosure (summary of invention) discloses , page 7, lies 11-14, 17-18 as 
follows: 

"the present invention is related to an intelligent policy server system and method for 
providing multiple service policy service policy feature or option and for managing bandwidth 
usage in the an ATM network. . . which policy server is also referred as a Multi-Service Control 
Point or MSCP..." 

As recited in above rejection, Buyukkoc discloses in col. 11, line 5-15, as follows: 

"The RSD may be used in conjunction with a number of other innovations. For example, 
the RSD may be used in conjunction with a service control point (SCP) of an Intelligent 
network. An SCP determines an appropriate destination for a call having more than one possible 
destination, such as a call to the 800 number of a large customer that may be routed to one of a 
number of regional service centers, based on factors such as the availability of representatives in 
the various service centers. The RSD may be accessed after an SCP or at the same time as 
an SCP, and the same server may provide RSD and SCP functionality." (Emphasis added) 



Thus, it is clear that Buyukkoc's RSD is the applicant "policy server". 

II) Examiner asserts the applicant's "policy profile having a plurality of policy 
features" as RSD's "connection rules/policy such as connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion". 

Applicant disclosure discloses , page 7, lies 11-14, 19-21; page 7, line 1-7 as follows: 

"the present invention is related to an intelligent policy server system and method for 
providing multiple service policy service policy feature or option and for managing bandwidth 
usage in the an ATM network. . .A return message from the policy server determines whether 
a call connection can be made through the network or not. . .Depending on the triggers 
associated with a signaling message received in the edge switch, a particular feature is invoked 
and executed by the policy server. . .burst-size limit, class-of-service provisioning, maximum 
concurrent call connections in progress, bandwidth control. . .are provided as exemplary 
features implemented in a presently preferred exemplary embodiment of the present invention.." 
(Emphasis added) 
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As recited in above rejection, Buyukkoc discloses as follows: 

"For each (source, destination) pair in the network, the RSD contains some or all of the 
following information. Depending on the needs and size of the network, a "destination" could be 
a terminating switch or it could be a trunk group or virtual path. Connectivity information 
regarding the set of routes that can be used to interconnect the source and destination. 
Information about alternate routes. Information on the capacity of each route in the network. 
Status of all of the routes in the network. Status could be in the form of free or available 
capacity or utilization on each link, or could be a status indicator such as "lightly loaded", 
"heavily loaded", "extreme congestion". The data needed to manage routing features 
responsible for distributing load to multiple physical destinations based on some rule or 
logic. 

Tables VII-IX show a sample RSD for the network of FIGS. 1-5. The Tables show 
information for only a limited number of routes, whereas a real RSD would have more complete 
information. In particular, if there are k routes between each pair of edge nodes and n edge 
nodes in the network, the total number of rows in the Route Status Table (Table IX) is kn(n-l)/2. 
The .alpha.-link, .beta.-link, source, destination, and VPI numbers of Tables VII-IX refer to the 
reference numbers of FIGS. 1-5. 

Table VII contains the current usage of each .alpha.-link. Table VII also contains 
two congestion thresholds for each link, which define three congestion status ranges — 
referred to as "green," "yellow," and "red," in increasing order of congestion. A status of 
"green" may mean that the route has plenty of capacity left and that new calls can be routed there 
with no difficulty. A status of "yellow" may mean that the link is beginning to get congested and 
that alternate routes should be used if available. A status of "red" may mean to avoid using the 
route if at all possible. For example, if a call arrives and all its possible paths are "red," the call 
may be blocked, depending upon its priority. For example, .alpha.-link 214 has a "green" 
congestion status when the usage is not greater than 1 .4 Gbps, a "yellow" congestion status when 
the usage is greater than 1.4 Gbps and not greater than 1.8 Gbps, and a "red" congestion status 
when the usage is greater than 1 .8 Gbps. The current usage of .alpha.-link 214 is 1 .312 Gbps, so 
the congestion status is "green." The current usage and congestion status of each link are 
periodically updated. It may be desirable to define different congestion thresholds for different 
links, due to factors such as different capacities and different expected usage volumes. In 
addition, it is preferable to incorporate a safety margin of additional capacity into the thresholds, 
because there is some potential for the information in the RSD to be slightly inaccurate or 
outdated. While Table VII only shows 2 congestion thresholds that define 3 congestion 
status for each link, many more thresholds and congestion status may be defined to allow 
for load balancing, overload control, and priorities for different quality-of-service traffic. 

Table VIII gives the status of the .beta.-links in the network. The information in Table 
VIII is similar to that in Table VII, but applies to .beta.-links instead of .alpha. -links. 

Table IX gives the Route Status Table. The .alpha. -links and .beta.-links associated 
with each route are identified, and the congestion status for each route is maintained. The 
congestion status can be periodically updated from the individual link congestion status 
information in Tables VII and VIII. There are many possible methods for defining Route Status 
based on Link Status. Route Status could be defined as equal to the status on the most congested 
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link in the route, or as an average of the congestion status values for each link in the route. Many 
other definitions are possible, and the present invention is not intended to be limited to any 
particular set of definitions. The Route Status values in Table IX are based on using the status of 
most congested link on the route from Tables VII and VIII. . ." see col. 9, line 50 (Emphasis 
added). 

"For example, a particular RRSDS 740 may receive information from several edge nodes 
720 regarding the amount of bandwidth that each of the edge nodes uses on a particular .beta.- 
link 715. RRSDS 740 may aggregate this information into a single piece of information that 
represents the total bandwidth used on the particular .beta. -link by those edge nodes 720 that are 
connected to the particular RRSDS 740. CRSDS 730 receives information from each RRSDS 
740, and uses this information to compute the total bandwidth usage on each .alpha.-link and 
each .beta. -link..." see col. 13, line 36-46. 



In addition, Buyukkoc also discloses 

"A new call arrives at originating switch 270, which determines that the call is destined 
for switch 220. The (origination, destination) information is passed to the RSD, which contains 
the information shown in Tables VII-IX. If there are different possible bandwidth 
requirements for different types of calls, the bandwidth requirement is preferably also 
passed to the RSD. The RSD uses the information in Table IX to determine that the best 
route from switch 220 to switch 270 is B2, with a congestion status of "green." The RSD 
then increments the current usage and congestion status entries for .alpha. -links 224 and 
214 in Table VII and .beta.-links 118 and 116 in Table VIII. Several techniques could be 
used to update the Status Field in Table IX. For example, it could be updated periodically, or 
upon a change in a congestion status. When the call ends, or does not make a successful 
connection, switch 220 and/or switch 270 sends another message to the RSD, and the RSD 
decrements the current usage on the applicable .alpha.-links and .beta.-links. . ." see col. 17, line 
30-49. 

"Class-of-service on an end-to-end basis may be implemented using the RSD. Using 
Method 8, for example, the originating edge node passes a class-of-service indicator to the RSD 
in addition to the origination and destination information for the call. The RSD uses the Route 
Status in Table IX to give priority to the more important calls. For example, if the Route 
Status is Green, any call can use the route. If the status is Yellow, only high priority calls can 
use the route, and if the status is Red, only the most critical calls can use the route. This example 
may be generalized to additional congestion status levels. Alternatively, the RSD can route only 
a fraction of calls of lower priority on more congested routes. For example, if the Route Status is 
yellow, then a rule might be that 25% of low priority calls and all of the high priority calls can 
use the route. . ." see col. 18, line 25-40. 



Thus, it clear that the applicant exemplary policy/rule/plan features of a policy profile 
such as "burst-size limit, class-of-service provisioning, maximum concurrent call 
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connections in progress, bandwidth control" clearly disclosed by Buyukkoc's SCP 
policy/mle/administration/guideline/plan/procedure/scheme having plurality of features such as 
bandwidth control/management, class-of-service, and/or loading/congestion of network (i.e. 
concurrent calls connection in progress) as defined in detailed by tables VII -IX. 

III. Examiner asserts applicant's "at least one policy profile" as Buyukkoc's "quality of 
service priority of a request call". 

Buyukkoc discloses: 

"Table VII contains the current usage of each .alpha.-link. Table VII also contains two 
congestion thresholds for each link, which define three congestion status ranges —referred to as 
"green," "yellow," and "red," in increasing order of congestion. A status of "green" may mean 
that the route has plenty of capacity left and that new calls can be routed there with no difficulty. 
A status of "yellow" may mean that the link is beginning to get congested and that alternate 
routes should be used if available. A status of "red" may mean to avoid using the route if at all 
possible. For example, if a call arrives and all its possible paths are "red," the call may be 
blocked, depending upon its priority " in col. 14, line 35-46. 

Thus, it is also clear that applicant "one policy profile" is disclosed by Buyukkoc as 
"quality of service or priority of a new request call" where a new call has a priority associated 
with different quality of service, and RCD invokes "priority or quality-of-service" rule/policy 
such as "green", "yellow" or "red" for establishing a call based on its request. 

Moreover, it also clear that Buyukkoc discloses determining if a particular policy feature 
is to be invoked (i.e. bandwidth control/management, class-of-service, and/or loading/congestion 
of network (i.e. concurrent calls connection in progress) in a policy server/RSD, based at least in 
part on said signaling/request message, and if so, determining in accordance with a 
rule/policy/guide line of bandwidth control/management, class-of-service and/or 
loading/congestion of network (i.e. concurrent calls connection in progress) for request/signaling 
message and as set forth above rejection. 
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Conclusion 

22. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to IAN N. MOORE whose telephone number is (571)272-3085. 
The examiner can normally be reached on 7:30 AM- 4:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Derrick W. Ferris can be reached on 571-272-3 123. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Ian N. Moore 
Primary Examiner 
Art Unit 2463 

/Ian N. Moore/ 

Primary Examiner, Art Unit 2463 



